2.1 Field of the Invention
The invention relates to a method and a system for discovering and documenting the business knowledge used to originally create and subsequently amend existing software applications (a process commonly referred to as “business rule extraction” or by the acronym “BRE”) for the purpose of documentation or for the purpose of creating or deploying software applications which partially or wholly replace parts or all of the existing software application with functionality that broadly serves the same or a modified business purpose. The invention uses a novel method that overcomes the inherent limitations of previous attempts to do the same using different methods. The invention may be used to complement or replace existing methods or products.
2.2 Description of the Related Art
2.2.1 General Business Rule Extraction
When programmers create a completely new software system using traditional languages such as COBOL, C, or Java, they do so from a set of functional and non-functional requirements that specify precisely what each function must do and what each non-functional characteristic must be. Functional requirements are further specified by association with business rules that specify precisely how each such function shall perform its task. The job of the programmer is to take these requirements with associated business rules and create program source code that, when rendered into executable form, will operate in accordance with the requirements and associated business rules.
Business rule extraction reverses this programming process. Business rule extraction is the process of analyzing programming artifacts when the functional requirements (with associated business rules) and the non-functional requirements may not be known, or perhaps only known imperfectly due to errors and/or omissions. Those artifacts include (but are not limited to) program source code, database specifications, online screen layouts, user documentation, operational instructions, and the like.
Testing software is the process of observing whether an executing program's behavior conforms to those functional requirements and associated business rules. By definition, these requirements are known. Thus test cases can and will be employed to observe whether the execution of the program produces the expected results, since the expected results are known from the requirements and associated business rules (see FIG. 1).
Dynamic business rule extraction reverses the process of testing. In a novel use of a standard process, the program's behavior is used to discover and remediate errors and omissions in the knowledge of the functional requirements and associated business rules that underlay the processing of the existing program (see FIG. 2). In so doing, the problem of errors and omissions in extracted business rules from all other BRE processes is solved. Test cases will reveal errors in the extracted business rules. Coverage analysis will reveal omissions in the extracted business rules.
Both the purpose and the remediation efforts for testing and for dynamic BRE are inverted. The remediation of observed defects in behavior during the testing process will require revision to the program until its behavior correctly corresponds to the functional requirements and associated business rules. Conversely, observed errors and omissions in the understanding of the functional requirements and associated business rules will require revision to that understanding until they both fully correspond to the behavior of the program.
Business rule extraction is most frequently a purely manual process, in which the process of business analysis will include interviews with subject matter experts and other knowledgeable individuals, and a manual review of the artifacts associated with the application, including but not limited to application source codes, other machine readable information, documentation in printed and electronic form, and other non-machine readable information. This process suffers significantly from errors and omissions in the results, increasing disproportionately with the scale of the computer application software system.
Some vendors offer a fully automated business rule extraction service by analysis of the program source code which results in a form of algorithmic business rules. Because of inherent limitations on what can be inferred using program source code analysis techniques, the results suffer because logically related program code may lose those relationships. The consequence is that the results are difficult to use and contain errors and omissions which are not obvious.
There are a number of products generally available which meet the definition of static business rule extraction discussed below in section 2.2.3. These products are semi-automated and produce results which are better than manual business rule extraction and better than the automated business rule extraction, yet still suffer from errors and omissions.
The job of the business rule analyst is to take the relevant set of existing application program artifacts and work backwards from the completed program to derive the algorithmic steps associated with each function and from them infer the original statement of the business rules, including any subsequent amendments or other updates. The purpose of deriving the original business rules is for generating documentation, for use in creating a partially or wholly replacement system, or both.
It is not unusual for business analysts and others who created those original requirements to casually blur the distinction between “requirements” and “business rules.” Herein we strictly define “functional requirements” as what each function must do and the associated “business rules” as how that function shall operate. (All definitions are drawn from those documented in section 5.2, and if there is any conflict between a definition given in context and the equivalent definition in section 5.2 then the latter shall prevail.) We are concerned only with the functional requirements because only functional requirements have associated business rules. We will not further consider non-functional requirements herein.
Many of the problems associated with creating a replacement system result from ambiguities in the human language expression of these business rules, and/or errors and/or omissions in the detail of these business rules, all of which must be discovered during the course of development and testing of any planned replacement software application in order to create the desired result. Testing, which is typically based on the requirements, is by definition blind to errors and omissions in the business rules associated with those requirements. Hence, the common experience of replacing large scale existing software applications is for them to exhibit serious and potentially destructive functional defects when placed into production, even after passing what was thought to be a thorough and comprehensive set of tests. These defects lead to extended periods of time to correct as well as significant cost overruns. Latent defects, which may not occur immediately or may not be recognized immediately, will remain in the operating software application to create future problems and incur future costs.
As a consequence, the only complete, correct and unambiguous expression of the functions and business rules from a non-trivial existing software application consists of the source codes of the programs that are used to create the executable form of the programs, and which comprise that existing system.
For the same reason, any documentation associated with a non-trivial, existing software application will inevitably contain errors, omissions and ambiguities, quite possibly very significant ones. If such documentation is used for the purpose of creating new software to partially or wholly replace the existing systems, then that will lead to extended periods of time to correct in any replacement system as well as significant cost overruns in the project to create and deploy that replacement system.
Business rules associated with functional requirements are usually stated as an abstraction. The following is an example of an abstract business rule:    a) “Do not allow the balance in the account to go below zero when processing a debit transaction.”
In the course of programming, each abstract business rule will be reduced to a series of algorithmic steps. The following is a simple example of an algorithmic business rule which is equivalent to the example abstract business rule above:    a) Validate the incoming debit transaction by testing that all data elements with a numeric type contain numeric values, and that there are no low level technical errors in the format of the transaction    b) Read the account record equivalent to the account number in the transaction and lock the record to prevent other concurrent updates    c) If there is a low level technical error reading the account record, reject the transaction and exit the algorithm    d) If the account record does not exist, reject the transaction and exit the algorithm    e) If the account record does not show a status of “open”, reject the transaction, abort the update of the account record, unlock the record and exit the algorithm    f) Reduce the account balance in the account record by the amount of the debit    g) If the resulting account balance is less than zero, reject the transaction, abort the update of the account record, unlock the record and exit the algorithm    h) Process the debit transaction, update the database, unlock the record, and exit the algorithm
There are many definitions of a “business rule” but for business rule extraction the best definition was derived by the Business Rules Group (formerly, known as the GUIDE Business Rules Project)1, which defines “ . . . a business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system.” In other words, a business rule is associated with allowing or rejecting a change of state within the persistent data store.
Business analysts and business personnel in general think of “business rules” as the abstractions, whereas programmers think of “business rules” as the algorithmic steps. Both definitions are consistent with the Business Rules Group definition. Herein, when a distinction is necessary for clarity, we shall refer to “abstract business rules” or “algorithmic business rules.” When a distinction is not necessary, we shall refer to “business rules” as meaning either one or both. The principal reason for making the distinction is that it is significantly more expensive to derive abstract business rules from the algorithmic business rules than to derive algorithmic rules and stop. Some projects will require extracting the abstract business rules while others may require only extracting the algorithmic business rules.
In general, use of the algorithmic business rules is usually sufficient when implementing a business rule management system within an existing application, or when rewriting parts or all of an existing system to preserve the existing functionality. Unless desired for documentary reasons, the extra expense of creating abstract rules is unlikely to be cost justified in these circumstances. Conversely, use of the abstract business rules is usually necessary when replacing an existing system with a commercial off the shelf package or when redesigning the existing system in some fundamental way to be followed by a new implementation of a replacement system. These are guidelines, not prescriptions or requirements.
The invention described herein is concerned with extracting algorithmic business rules without errors or omissions, which may or may not be subsequently abstracted into abstract business rules, and validating the algorithmic business rules and/or the abstract business rules as is relevant in a given instance.
Functional requirements may be associated with an event that could create a change of state in the persistent data, defined as an update transaction, or it may be associated with inquiring on data in the persistent data store, defined as a query transaction, which will not create a meaningful change of state. Therefore, where a distinction is relevant, we define the business rules associated with update transactions as “transactional business rules”.
The transactional business rules directly associated with functional requirements also depend on the concepts, entities and relationships that define both the transient and persistent data. We define these concepts, entities, attributes and relationships as “conceptual business rules” which may be used by both query transactions and update transactions. When a distinction is not relevant, we use “business rules” to include both the transactional business rules and the conceptual business rules which give meaning to the transactional business rules.
Loosely speaking, the conceptual business rules describe the data with their relationships, and the transactional business rules describe the details of the executable program instructions. This is an oversimplification but may help clarify the distinction.
There are also some programs that update the persistent data store under circumstances other than the occurrence of an event, such as a rules driven process that evaluates the contents of the database based on a difference in time or other attribute of the persistent data store. These are batch programs since they are not associated with any event such as the arrival of a message transaction. These rule driven processes are defined as “periodic batch programs”. Although these processes are not actuated by the arrival of a message transaction, because they are associated with a change of state in the database each such update of the persistent data also constitutes an update transaction, and the business rules that govern the selection of data and the decision to update that data also constitute transactional business rules.
To summarize, the relationships between requirements and business rules can be expressed as follows:    a) Set of all requirements            i) Subset of non-functional requirements                    (1) (No associated business rules)                        ii) Subset of functional requirements                    (1) Subset of query functions                            (a) Associated conceptual business rules                                    (2) Subset of update functions (including periodic batch programs)                            (a) Associated conceptual business rules                (b) Associated transactional business rules                                                
The Business Rules Group business rule definition refers to transactional business rules which implicitly incorporate conceptual business rules, and this is the rigorous definition that we use, i.e., both transactional business rules and conceptual business rules. However, query transactions, which by definition do not create, update or remove persistent data, do utilize conceptual business rules. This finer distinction extends rather than contradicts the Business Rules Group definition.
Because of this definition, BRE always applies to update programs, even those which have a query capability as a component of their functions, but only rarely to query only programs. Analyzing the query logic in a query program or in a query component of an update program can expose a previously missed conceptual business rule, but in practice this is rarely done. Doing so is a matter of professional judgment by the project team. Many projects will analyze no query programs at all.
Returning to our example, conceptual business rules would define the “account” entity with its associated attributes such as the balance, as well as other entities which relate to the account such as the transient transaction data, the persistent history of previous transactions and the relationship among all such entities. Conceptual business rules also define reference data such as parameters that control the processing of debit transactions for this type of account and define transient data such as that used to perform the arithmetic to apply the amount of the debit transaction to the existing balance in the account.
When performing business rule extraction, the business rule analyst must first determine enough of the conceptual business rules to define the meaning of the functions to be subsequently analyzed and to create a vocabulary that can be used to analyze and describe the functions and associated transactional business rules. This is typically begun by analyzing the existing data model prior to beginning any business rule extraction.
During business rule extraction, these conceptual business rules may be extended and perhaps amended based on new discoveries during the analysis of the program(s) by whatever method. As transactional business rules are discovered within the program(s) and added to the set of identified transactional business rules, the concepts that they reference may be found to not exist within the set of identified conceptual business rules or the concepts may indicate errors or omissions within the set of conceptual business rules. If so, then the set of conceptual business rules will be extended or amended accordingly.
Transactional business rules depend on conceptual business rules to give them meaning. The conceptual business rules are universal across all functions in that they can be used anywhere within the scope of the application system. When using the invention to extract transactional business rules, errors and omissions in the understanding of the conceptual business rules become clear, so the invention applies to both conceptual and transactional business rules.
Transactional business rules are directly associated with specific functions and thus are implicitly local rather than universal. The set of transactional business rules associated with each function may be completely disjoint, partially overlap, or completely overlap the respective sets of transactional business rules associated with each of the other functions of the software application. In summary, conceptual business rules are always universal to the software application while transactional business rules could in theory be universal but typically are not.
When performing business rule extraction, the business rule analyst must determine, for each discovered function, that there is one or more associated business rules, then find and document the algorithmic steps that are the programmatic expression of each business rule. If abstract business rules are required, then the business rule analyst must also interpret those steps to recreate the original abstract expression of the business rules, but this abstraction is a distinct and separate process from deriving the conceptual business rules and the programmatic steps of the algorithmic business rules.
In the process of performing the analysis, the analyst may also discover and document previously undiscovered functions, but doing so is incidental to business rule extraction and does not enter into this description except insofar as previously unknown business rules are associated with a newly discovered function. The entire process of business rule extraction is iterative in the sense that the business rule analyst begins with what is known or thought to be known about the business rules of the system, and then refines and extends the analysis until complete.
In the process of documentation, the algorithmic and/or abstract business rules may be expressed in a human language such as English, in a pseudo-code, in a formal computer language, in a business rules language, in a business rules decision table, or in any other form which may or not may be directly executable and which may or may not preclude ambiguities in their expression.
2.2.2 Coverage Analysis
The execution of a program under conditions that allow the recording of the logic paths that are actually executed within the program is typically called code coverage analysis, test coverage analysis, test code coverage analysis, or simply coverage analysis. Coverage analysis is a technique of long standing for aiding the process of testing software programs against both functional and non-functional requirements. By the nature of software testing, the requirements are known and it is the behavior or nature of the program which is being analyzed for conformance with those requirements. All discussions of coverage analysis researched to date have related to this purpose of testing against known requirements, both functional and non-functional.
Each logical decision point in a program creates two logical pathways for subsequent execution, one in which the decision results in a true condition, and the other in which the decision results in a false condition. Coverage analysis, summed over the execution of one or more test cases, records the cumulative execution results for each decision point in a program, whether:    a) the true logic path was executed,    b) the false logic path was executed,    c) both logic paths were executed, or    d) neither logic path was executed.
The coverage analysis report may or may not report false logic path coverage if the false logic path is implicit rather than explicit.
The coverage report may or may not separately report true and false results from each component conditional statement of a compound conditional statement.
The scope of coverage reports is determined by the number of test cases used for a test execution of the program and the content of each test case. If only a single test case is used after resetting the counters used to record the execution of instructions, then only the logic associated with that one transaction will show as executed in the report. If more than one test case is executed at a time, or multiple executions without clearing the counters, then a cumulative coverage analysis report results showing the code executed by any of the test cases. If all test cases are executed then the resulting cumulative report that is produced may indicate omissions in the test cases and thereby determine additional test cases that may need to be created to meet coverage goals.
Testing against expected results is a “black box” test—do the inputs result in the expected outputs? Testers are typically not programmers, do not typically debug a program which fails conform to requirements, and typically have no knowledge of the internals of a program. Although black box testers do not typically examine the internals of the program, they may create cumulative coverage analysis reports to determine whether or not their tests have reached some specific overall coverage percentage, typically 80% or 90%. In this regard, their interest may be only in the statistics from the report, not the executable statement content.
Coverage analysis is a “white box” process, in which the internal instructions of a program are revealed to those who will utilize the resulting reports, both those statements executed and those statements not executed. When utilized for dynamic BRE, it is this white box mode in which coverage analysis is used, particularly for the single transaction coverage analysis reports.
2.2.3 Static Business Rule Extraction
All existing products and automated techniques for discovering business rules in existing programs analyze the source codes of those programs and only the source codes, i.e., the human readable program code that is translated into executable object form prior to production execution. In other words, the analysis of a program source code by existing technologies is static, meaning that there is no change in the state of the program during the analysis, hence the term “static business rule extraction” (or “static BRE” for short) to distinguish it from the invention described herein for which we use the term “dynamic business rule extraction” (or “dynamic BRE” for short).
Earlier attempts to automate business rule extraction are either fully automated or are semi-automated in which a static business rules analyst will research the source code of the existing application using an interactive analytical utility which uses parsing tools originally derived from compiler design and implementation. (See, for example, U.S. Pat. No. 6,389,588, “Method and system of business rule extraction from existing applications for integration into new applications”.)
The logic paths that are executed when the program is in use must be inferred by the static business rules analyst, since it is not actually executing. The greater the level of complexity of the program, the greater the number of ambiguities and missed interrelationships that arise in this inferencing process. The level of complexity increases disproportionately with the size of the program. Therefore, this inferencing process will be weakest in the largest, most complex, and usually most important programs within the application system.
Inferential analysis cannot by its nature eliminate all ambiguities in non-trivially complex programs. Consequently, there is no clear test or rigorous definition which a static BRE analyst can use to determine when or if they have reached 100% of the business rules to be extracted. In practice, static BRE will usually stop before identifying all of the subtle interactions among a significantly sized program's many strands of logic and the reference and transactional data that drives the logic.
This inferential approach, while a distinct improvement over the purely manual methods that preceded it, fails to capture all of the business rules in programs of non-trivial complexity and has no method for unambiguous validation of the extracted rules, resulting in both errors and omissions in the resulting business rules. The limitations of static BRE are discussed in more detail in section 2.3, as well as a description of how dynamic BRE overcomes these limitations.
Similarly, when the BRE analyst records the business rules extracted in a human language such as English, there is an opportunity for additional ambiguities to be introduced. When a programmer utilizes these expressed rules there is the opportunity for further errors of interpretation to occur. There is no clear test or rigorous definition by which a consumer of the extracted business rules can determine whether or not the resulting extraction contains errors and/or omissions, except through the method and system used by the invention.
2.3 Technical Comparison of Static and Dynamic BRE
As discussed above, testing observes whether or not the behavior of a program under test conforms to the expected behavior of known functional requirements with known associated business rules. In business rule extraction, it is the unknown or imperfectly known business rules associated with the program's functions that we seek to discover.
For dynamic BRE, the state of the program is constantly changing during the course of the analysis. In dynamic BRE we pursue our discovery by observing the behavior of a program's internal execution to expose a set of previously unknown or imperfectly known business rules, and then to validate that we have done so.
Both testing and dynamic BRE execute the program against test cases, but with different purposes and different outcomes. With testing we know the functions and business rules but the behavior is uncertain. Conversely, with dynamic BRE we stipulate that the behavior of each program is correct and seek to discover the unknown or imperfectly known business rules that are associated with the program's functions.
The problems of static BRE that dynamic BRE seeks to overcome are the ultimately ambiguous results from the inferential analysis of the program source codes which leads to errors and omissions in the results, and the lack of any clear and rigorous test by which an analyst can judge that their analysis is complete. Dynamic BRE provides a solution for both shortcomings of static BRE, and is fully scaleable to 100% of the business rules which static BRE is not, for programs of significant size and complexity.
Dynamic business rule extraction utilizes a novel method to eliminate these ambiguities and provide 100% of business rules and furthermore document forensically that it has done so. The invention utilizes coverage analysis in a novel way and for a novel purpose in order to solve the very real business problems created by these shortcomings in static BRE.    a) The novelty of the coverage analysis usage with dynamic BRE is that we prepare single transaction test cases and then create a coverage analysis report showing only the lines of source code executed by each single test case.    b) While historically coverage analysis has always been associated with testing, i.e., where the business rules are known and the behavior of the program is uncertain, the novelty of the purpose is that it is being applied to reverse the usual paradigm: to discover the business rules that are unknown or imperfectly known. In doing so it allows the solution to both shortcomings of static BRE.
The invention is based on analyzing the actual execution path during execution against actual data of the compiled object code version of the source code as opposed to the inferred execution during static BRE against data imagined by the static BRE analyst. The object code actually executed with coverage analysis is linked back to the source code so that the dynamic BRE analyst sees a report showing the source code that was and was not executed. Analysts using each method work from the source code, but the dynamic analysis is based on deterministic program code execution while the static analysis is based on inferential program code execution.
Coverage analysis is used in two ways during dynamic BRE:    a) The single transaction coverage analysis report is utilized to discover the business rules associated with the single transaction test case with its unique set of data conditions. This solves the inferential problem with static BRE by enabling a fully deterministic analysis.    b) The cumulative coverage analysis report resulting from the sequential execution of all test cases for a given program is used to determine whether we have achieved 100% coverage in our set of all test cases. This second report solves the problem of static BRE not having a clear and rigorous definition of completion. This report also provides the forensic documentation that the extracted set of business rules are complete, for audit traceability purposes.
A second method of following the program execution could be through the use of an interactive debugger. These utilities provide the ability to not only follow the logic paths actually executed by the program under test, just as is provided by the single transaction coverage analysis reports, but also provides the ability to stop and examine or even modify the values of data variables in memory during the course of code execution for an even deeper understanding, which is not provided by the coverage analysis report. However, this method is so labor intensive and time consuming that it is impractical to use except under rare circumstances. This is an adjunct utility to use in special cases when the single transaction test cases have a scope of execution that is greater that which is desired to reveal the detailed actions of the executing business rules.
The invention also optionally allows for the creation of a Business Rule Execution Path Report which records additional details from the execution to use for an extended analysis in circumstances for which the use of an interactive debugger might otherwise be considered. While this report can frequently be voluminous, it is significantly more efficient for the purpose of eliciting these fine details than an interactive debugger. Among other things, one can back up during analysis of the recorded information, whereas most implementations of interactive debuggers do not allow one to do so.
Completion of dynamic business rule extraction is defined as 100% of the logic paths in the program being executed or explained, either as not being able to be executed or why it is not necessary to execute that logic path. A more complete discussion of explained logic paths is given in the detailed description in section 5.7.
Furthermore, in contrast to static BRE, dynamic BRE can objectively determine whether or not the extracted business rules are valid, as well as documenting forensically that it has done so. We validate the extracted business rules when we take the test cases developed in the process of dynamic BRE against the existing programs, adapt the data and transactions from those tests to the formats used in any replacement system, and execute them against the functionally equivalent modules in the replacement system, thus proving empirically that they are valid by demonstrating equivalence. In other words, during dynamic BRE validation we demonstrate that the reproduced business rules constitute the complete set of business rules without errors or omissions.
The coverage reports created by the execution of the test cases against the existing programs and against the replacement system's program(s) creates the forensic documentation.
This use of test cases derived from the existing program(s) against the replacement program(s) is both novel and non-obvious. Testers develop test cases based on requirements, so that the testers work from the documented functional requirements and documented associated business rules. If these contain ambiguities of expression then the test cases themselves can be as potentially defective as the replacement program(s) themselves, assuming they were built against the same ambiguously expressed functional requirements and associated business rules. Only the machine readable test cases that were validated against the existing program(s), correctly adapted to the replacement program(s), can reliably validate the implementation of the reproduced functions and associated business rules.
Each single update transaction test case executed against a program's replacement reveals any errors or omissions in the documentation of extracted business rules, in the interpretation of those documented business rules, and/or in the implementation of the replacement program. The coverage analysis report from the existing program that accompanies the test case and the coverage analysis report from the equivalent test execution against the replacement program also provides rapid and efficient diagnosis of any observed defect in the replacement program in which it failed to function equivalently.
The cumulative set of update transaction test cases executed against a program's replacement is expected to show 100% of the logic paths executed, since the explained logic paths from the existing programs are not carried forward to a replacement program. If any logic paths are not executed in the replacement, they need to be examined to see if they are the result of technical logic which does not impact the results of the program's execution. However, if there are unexecuted logic paths after excluding technical logic which does impact the results of processing, then they have to be analyzed to determine whether they constitute erroneously or maliciously added business rules.
Dynamic BRE can be used in place of static BRE, or as a complement to static BRE. Dynamic BRE deals with one program at a time, but does so to a greater depth than can usually be achieved by static BRE. However, the one advantage of static BRE is that it can search among all the source codes of the system for business logic associated with specific data conditions. This can be desirable in the situation where a given set of business rules is used in multiple locations in a single program and/or across multiple programs, but the implementation uses subtly different expressions of the rules that, under certain circumstances, can give rise to a different result. Static BRE can thus identify multiple locations where the dynamic BRE analysis needs to focus in order to explore the similarities and differences among the multiple implementations. This is useful and so, in general, one might expect to see static BRE complementing dynamic BRE more often than using dynamic BRE by itself.
Summary of Comparisons Between Use of Coverage Analysis forTesting and Use of Coverage Analysis for Dynamic Business RuleExtraction To Demonstrate Novel UseDynamic BusinessUsageTestingRule ExtractionUsage ofSingle transactions areSingle transaction coveragesingletypically used to test thereports provide the primarytransactionresults against knownmethod of observation of the coverageexpected results from thosebehavior of the program foranalysisdata conditions. Coveragedynamic BRE purposes. Theyanalysis is used only withare used to determine theregard to the percentage oflogic paths executed by thatprogram code covered. Thetransaction and thereby leadinternals are typically neverto discovery of unknown orexamined by testers.imperfectly known functionalrequirements and associatedbusiness rules and/or of errors and omissions in thefunctional requirements andassociated business rules.Usage ofCumulative coverage analysisCumulative coveragecumulativeis typically used to determineanalysis is used totransactionwhether or not testingdetermine whether or notcoveragehas reached a pre-definedthere are remaining potentialanalysisthreshold of coverage.omissions in the business rules(Testing is typically(i.e., logic paths neitherhalted prior to 100%.)executed nor explained)?
Summary of Technical Comparison of Static andDynamic Business Rule ExtractionStatic BREDynamic BREState of programStaticDynamicAnalytical deviceAnalysis ofAnalysis of source code withstandaloneactual execution path informationsource coderecorded by the executingwith parsersprogram code against data.Execution pathInferredActualData driving theImaginedActualexecutionType of analysisInferentialDeterministicObjective measureNoYesof completionUnambiguousNoYesvalidation of correctbusiness ruleextractionUse of single testN/AIlluminating logic paths executed case coveragefor each update transaction againstanalysis withexisting program for businessexisting programsrule discovery and extractionUse of cumulativeN/ADetermining completeness oftest case coverageanalysis and revealing potentialanalysis withomissions in the business rulesexisting programsUse of single testN/ATest cases validated againstcase coverageexisting programs when adaptedanalysis withfor replacement programsreplacementwhich are subsequently executed programsreveal errors or ambiguitiesin business rule documentation,interpretation and/or implementation. Coverage report aids debuggingby comparison with coveragereport from existing program.Use of cumulativeN/AIdentifies added business rulestest case coveragethat may be the result of potentialanalysis withprogramming errors orreplacementpotential malicious coding.programsScope of analysisOne or moreOne program at a timeprogramsat a time2.4 Economic Comparison of Static and Dynamic BRE
Because dynamic BRE analyzes to a greater depth, it might be thought to be more expensive than static BRE covering the same programs. However, by our analysis, dynamic BRE is a bargain:    a) only the programs updating the persistent data store will be analyzed, which are typically 10-30% of the programs in an application suite of programs;    b) the cumulative coverage analysis test cases used for business rule validation and completeness also cover unit testing for the new application, eliminating that cost;    c) the replacement application can be expected to go into production with no discrepancies in the functioning of the business rules, an unheard of level of accuracy which eliminates what can be very considerable last stage costs for finding and debugging discrepancies in pre-production testing or in production operation.
The set of transactional and conceptual business rules associated with any one given function interacts among all the other sets of business rules associated with their respective functions to various degrees. The result is that the effort to extract each next business rule increases as the analysis proceeds. The larger the program the more business rules will be contained therein to discover and extract, and therefore the more this increasing effort impacts the overall effort for that program. These business rule interactions among each other as well as interactions among the various values of parameter data result in a degree of complexity and ambiguity that increasingly impacts any static business rule extraction project as the scale of the application increases. Eventually even the best and brightest business rule analyst will become progressively bogged down in the analysis, as sooner or later this escalating complexity will exceed any human's capability to hold in one's mind.
When using static BRE in projects, we have observed a relationship between the percentage of active business rules actually extracted as a function of effort expended that has approximately the shape of a classic diminishing returns curve (see FIG. 3).
There is a point of diminishing returns beyond which deriving business rules completely and correctly using static BRE from programs of non-trivial complexity becomes impossible in practice, and economically prohibitive. This point is reached at a different scale depending on the language, the implementation standards, and the degree to which the comprehensibility of a given application has degraded over its lifetime due to a large variety of factors, such as for example being maintained by multiple programmers each with different levels of competence and with different programing styles.
Regardless of precisely where the point of diminishing returns is located for a given program, all software programs of non-trivial complexity are subject to this problem of scale forcing static business rule analysis to halt prior to reaching the ideal goal, i.e., providing a 100% complete and correct set of business rules for each functional requirement. The resulting errors and omissions in the business rules of a replacement program show up as defects in the new software application, and can result in delays in deployment that can significantly increase costs and even, in extreme cases, result in project failure. Worse is the situation where the new application goes into production deployment with numerous undetected defects in the business rules. The cost of program and data repair when the system is in production is much, much greater than had the defect been detected at the outset of the new implementation.2 2 For one example, see Michael Lundblad and Moshe Cohen—IBM, March, 2009. Software quality optimization: balancing business transformation and risk.
Dynamic business rule extraction is also subject to diminishing returns but to a significantly lesser extent because    a) any residual ambiguities in understanding can be resolved by using an interactive debugging utility to step through the execution instruction by instruction until the ambiguities are resolved empirically or by using the Business Rule Execution Path Report, and    b) because we have an objective standard that defines when the business rule extraction effort is complete. “Complete” is defined to mean having analyzed 100% of the logic paths through the program(s) under analysis from the existing software application. In this case, “analyzed” means either by creating a test case with data conditions that force the program to execute that logic path or by explaining why it is not possible or necessary to execute that logic path.